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CSNET stands for the Computer Science Research Network , a project sponsored by NSF to pro¬ 
vide advanced computer network services to the computer research community. CSNET is a "logical 
net" - a high-level communication environment spanning several physical nets, including the 
ARPANET, Phonenet, and X.25 public packet-switched networks (e.g.. Telenet). This paper reviews 
the history, the goals, the organization, the components, and the status of CSNET as of Fall 1982. 


9 
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Background 

The seeds of CSNET were planted in May 1979. L. H. Landweber arranged a special meeting at 
the University of Wisconsin to discuss how computer network services like those of ARPANET could 
become available to the entire community of computer science researchers. The ARPANET served \ 
only a dozen university sites and DARPA was unable to include the rest of the community. 


It was clear to the participants that mail, file transfer, and remote login services had greatly 


enhanced research productivity and had generated a strong community spirit amon g ARPA NET sites. It 



was also clear that the ARPANET experiment had produced a split between me "haves" of 
ARPANET and the "have-nots" of the rest of the computer science community. The participants at the 
meeting wanted tcf unify the computer research co mmuni ty and to improve research conditions for all 
its members. 


Each participant at the meeting had previous, favorable experience with computer-based mail ser¬ 
vices for a small research co mmuni ty. One was "THEORYNET", a mailbox facility on a machine at 


2 __ 

More detailed information on the background and history of CSNET can be found in the article by Comer [1]. More 

detailed information about CSNET'S multinet architecture can be found in the paper by Landweber and Solomon [2]. 



CS NET Overview 


(12/1/82) 


- 3 - 


the University of Wisconsin accessible via Telenet login to some 200 theoretical computer scientists. 
Another was "SAMNET", a mailbox facility on a machine at the University of Toronto accessible to 
some 50 performance analysts. A third was "SYMBOLNET", a network linking four sites comprising 
researchers in symbolic computation; the goal was a network based on Telenet with services to mirror 
ARPANET (but to be independent of ARPANET). Each of these primitive electronic mail services had 
significantly aided its special community. Each community was anxious to obtain the more advanced 
services of machine-to-machine mail transfer, file transfer, and remote login. 

Also present at this meeting were observers from NSF and DARPA. The NSF was the sponsor of 
THEORYNET and SYMBOLNET and. on the advice of its advisory panel, had been alert for possible 
extensions of network services to the rest of the community. DARPA was interest^ in furthering com¬ 
puter science research and believed that network services might be a step of high leverage. These 
observers offered advice and encouragement 

The group determined to submit a proposal to the NSF. They envisaged a network available to 
all members of the computer science community. The network would have low entry costs and other 
costs proportional to usage. Public packet-switched networks, notably Telenet, would be the underlying 
medium. (At the time, a DARPA IMP cost about S90K per year, a price well beyond the means of 
most computer science departments. Moderate speed Telenet connections were then available for entry 
fees of about $20K per year.) 

In November 1979 the University of Wisconsin submitted a proposal to NSF containing the above 
plan on behalf of a consortium of universities (Georgia Tech, Minnesota, New Mexico, Oklahoma, Pur¬ 
due, UC-Berkeley, Utah, Virginia, Washington, Wisconsin, and Yale). The cost would be $3 million 
over a five-year period. The NSF had the proposal reviewed and returned comments to the proposers in 
March 1980. 

The reviews revealed a much higher level of skepticism than the proposers had anticipated. The 
skepticism had three roots. One was a belief that the CSNET project was proposing to reinvent 
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ARPANET technology; this perception was reinforced by the lack of any gateway between the 
ARPANET and the proposed CSNET. The second was a belief that insufficient attention had been 
given to project management and task distribution. The third was a belief that NSF might have to 
obtain funds for CSNET by reducing basic research budgets. On the basis of these reviews the NSF 
could not fund the project as proposed. 

^ == ”~But the NSF’s advisors and some of the reviewers adamantly maintained that CSNET would so 
improve research productivity that the potential diversion of funds from basic research would pay off 
handsomely in the long run. Accordingly, the NSF offered to fund a thorough study of the CSNET 
concept. The purpose of the study was to determine the most cost-effective architecture, to develop a 
sound management plan, and to assess the extent of community support. With sufficiently strong peer 
approval, CSNET would be possible. 

During the summer of 1980, Landweber convened a CSNET planning committee comprising 
nineteen computer scientists, a cross section of leaders of the community who had extensive computer 
network experience. Two major new factors entered the discussion. One was the existence of MMDF, 
software for "multi-channel memo distribution facility," under development at the University of 
Delaware [3]. MMDF is a UNIX-based mail transport system that sends and receives mail over a 
variety of channels including ARPANET and telephone. (The latter is functionally similar to the 
"uucp" facility of UNIX.) With MMDF, CSNET could bring a large number of sites online in a short 
period at low cost. 


/ 


The second factor was DARPA’s decision to proceed with "internet protocols" (IP) that permit a 
host in one net to communicate with a host in a different net With the internet protocols, CSNET 
could be regarded as a logical organization of users on different nets. DARPA offered to make its new 
protocol software (TCP/IP) available to the CSNET project In return, DARPA expected that the exist¬ 
ing ARPANET university community would be a component of CSNET at no cost to DARPA. 


The planning committee quickly reached a consensus. CSNET would include subnets based on 
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ARPANET, X.25 nets, and Phonenet (the MMDF service). The internet protocols would hide these 
. components from their users. CSNET would develop an interface between ARPANET’S protocol 
software (IP) and the X.25 public networks (initially Telenet); this would make the standard ARPANET 
services available to non-DARPA hosts. CSNET would provide a name server that registers all CSNET 
users and quickly locates the mailbox of any registered user. CSNET would initially receive full sup¬ 


port from NSF, but would become self supporting -within five years via dues and usage fees. 


A proposal containing this plan was submitted by Wisconsin on behalf of a consortium of institu¬ 
tions (Wisconsin, Purdue, Utah, Delaware, and The Rand Corporation) in November, 1980. It was 
reviewed by late December, 1980 and then submitted to the National Science Board, which approved 
the project in January 1981. The Board stipulated that the NSF would provide a $11 time project 
manager for the first two years but would withdraw from project management by February, 1983, when 
the CSNET organization would be strong enough to take over. Contracts for CSNET were let to 
Wisconsin, Purdue, Delaware, and Rand in late spring, 1981. After 20 months, the seeds of CSNET 
had begun to sprout The real work lay ahead. 


Goals 

The goals of CSNET are summarized in Figure 1. The net is to be open to all computer 
researchers throughout the United States (later, the world). It is to be self-supporting. Its users will 
pay fixed annual dues plus usage fees. (The dues for 1983 are shown in the bottom part of the table.) 
CSNET will initially comprise three subnets — ARPANET, Telenet, and Phonenet - but will be 
expandable to others as they become available, e.g., other X.25 public nets and satellite nets. CSNET 
will initially provide the same services as ARPANET -- mail, file transfer, remote login, and an on-line 
name server. Later, it will provide additional services such as messages containing voice segments, 
software libraries, technical report repositories, and an on-line journal. 
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COMPUTER SCIENCE RESEARCH NETWORK GOALS 


• Open to all computer researchers. 

• Logical net comprising physical subnets 

(initially ARPANET, Telenet. Phonenet). 

• Advanced network services 

(initially mail, file transfer, remote 
login, name server). 

• Self-governing, -sustaining, and -supporting 

• Low entry fee 


DUES FOR CALENDAR 1983 

< 

Industry site - $30,000 
Government site — $10,000 
Non-Profit site — $10,000 
University site — $5,000 

Note: Sites with a very small number of researchers can negotiate lower dues. 


FIGURE 1: Goals and Dues Structure of CSNET. 


The four project teams must carry out these goals within two important constraints. First, the 
total project budget, $5 million over five years, places a severe limit on the number of personnel who 
can be hired. It also means that satisfactory service must be available by 1983 to permit collection of 
dues. Second, the project must develop its own stable management organization by Spring 1983, when 
NSF withdraws officially from project management. 

Users who have accounts at ARPANET hosts already have the full services of CSNET except for 
the name server. Until Telenet sites are operational, all other users are at Phonenet sites; they will not 
have file transfer or remote login services and will interact with the name server by mail. At the start 
of the project, mailboxes are also provided on a machine called the CSNET Public Host for users who 
have no accounts at ARPANET or Phonenet sites; this service is not heavily used. 



CSNET Overview 


-7- 


- (12/1/82) 


CSNET protocol and name-server software development is limited to the Berkeley UNIX operat¬ 
ing system on VAX computers. The MMDF software works with Berkeley UNIX and Bell Labs’ Ver¬ 
sion 7 UNIX. CSNET is encouraging vendors to develop compatible software and hardware for other 

3 

machines and operating systems. 


Technical Projects 

Figure 2 lists the three technical subprojects of CSNET: Phonenet. Name Server, and Protocols. 
The following subsections give overviews of these projects. Companion papers ddScribe these projects 
in detail [1,2,3]. 


Phonenet 

The Phonenet project is being conducted jointly at the University of Delaware and the Rand Cor¬ 
poration. Its first goal is to set up and operate mail relay computers on the east coast (at the University 
of Delaware) and on the west coast (at the Rand Corporation). Its second goal is to provide each 
CSNET site with the MMDF mail transport to permit automatic mail exchange between that site’s 
machine and the nearest relay. 

Each relay will route mail to the destination site via ARPANET, Telenet. Phonenet, and possibly 
the other relay. CSNET sites can poll the relays as often as they desire and are willing to pay tele¬ 
phone line charges. Phonenet messages can incur usage charges if they are routed over paths for which 

3 

For example, the IBM Corporation has an agreement with the University of Wisconsin to develop CSNET-compatible 
protocols for IBM machines running the VM operating system. Also, a Pascal version of the Phonenet software has 
enabled Phonenet participation by users of DEC VMS and IBM VM operating systems. 
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PROJECT 

INVESTIGATORS 

GOAL 

Phonenet 

D. Farber (Delaware) 

A. Hearn (Rand) 

Install and operate mail relays (VAX 

11/750) at Delaware and Rand, connected 
by phone. Telenet, and ARPANET. Distri¬ 
bute copies of MMDF software to CSNET 
Phonenet sites. Goal is 100 operational 
sites by 1983. 

Name Server 

L. Landweber (Wisconsin) 

M. Solomon (Wisconsin) 

Develop the CSNET name server, a data¬ 
base of all CSNET users, and install it on 
the CSNET Service Host Final version 
distributed to CSNET sites by end of 1983. 

Protocol 

D. Comer (Purdue) 

P. Denning (Purdue) 

T. Korb (Purdue) 

9 

Construct interface between ARPA’s Inter¬ 
net Protocol (IP) and the X.25 public net¬ 
work protocol to permit using X.25 nets 
for full ARPANET services. Working ver¬ 
sion available for distribution by 1983. 


FIGURE 2: Technical Subprojects of CSNET. 


CSNET must pay, e.g.» telephone lines or Telenet. 

The design goals of MMDF have been reported at the 1979 Data Communications Symposium 
[3]. They are: 1) a mail transport that provides a high-level, channel-independent interface, 2) error 
checking of message formats, and 3) robustness under load. The main components of MMDF are illus¬ 
trated in Figure 3. 

The first goal is achieved by implementing the delivery mechanism as a process that takes mes¬ 
sages one at a time from its work queue and sends them over one of several channels connected to its 
output. The inco min g messages must consist of a body and a header in a standard (internal) format 
The delivery process uses the address in the header to select a channel for sending the message. Each 
channel is a driver that sends the message in the protocol of a particular network, e.g., local delivery. 
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ARPANET, UUCP, or Phone net. 

The second goal is met by requiring that every user mail environment contain a certified "submit" 
subprogram for interacting with the MMDF delivery process. When a user forms an address in the 
header of a message, the submit subprogram converts it to the standard internal form and checks with 
the delivery process to verify its validity; if the address is invalid, the user is immediately notified. 
When the user completes the message body, the submit subprogram deposits the ready message with 
validated address in the work queue of the delivery process. 

Mail incoming on any channel is also placed in the work queue of the delivery process, which 
will eventually deposit it in a local mailbox via the local delivery channel. 

© 

The third goal is met by storing the work queue of the deliver process on secondary storage, 
which can allow it to become quite large without overloading the system. 

CSNET soon encountered difficulties on account of an essential incompatibility between the 
MMDF transport and the one already in the UNDC operating system at each of the Phonenet sites. The 
regular UNDC mailer programs do no address checking; instead, the delivery process parses and inter¬ 
prets addresses of many formats. There is no simple way to convert these mailers to interact with the 
MMDF delivery process directly. Because of this, many Phonenet sites had to deal with two mail sys¬ 
tems -- the one already in their UNDC operating systems and the new one provided by MMDF. This 
was a major inconvenience that created many complaints. 

To provide a temporary solution, the Purdue and Delaware contractors cooperated on minor 
modifications of delivery processes of Berkeley UNDC and MMDF. The Outgoing ARPANET channel 
on the Berkeley delivery process was replaced with a driver that hands mail intended for the 
ARPANET to the MMDF delivery process, which in turn routes it to its destination via the Phonenet 
channel. (Because Phonenet sites cannot send directly to the ARPANET, this loses no function.) The 
MMDF local delivery channel was modified to store mail in the mailboxes and in the formats expected 
by the Berkeley mail programs. The disadvantage of this solution is that it requires each Phonenet site 
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to install and maintain two mail transport systems. 

A long-term solution is being discussed between CSNET and the Berkeley UNIX developers. 

The goal is a single mail transport that incorporates the best features of Berkeley’s current mail system 
and MMDF. This system would be distributed with releases of Berkeley UNIX. 


Name Server [4] 

The name server is a database of all CSNET users held online at a site called the CSNET Service 
Host. (This machine is now at the University of Wisconsin.) Each record of this database contains the 
name, mailbox identifier, and descriptive keywords of a registered CSNET user. CSNET sites can 
query the name server to obtain the mailbox address of any user. CSNET users can update the key¬ 
words in their records at any time. The name server project is also implementing the programs to be 
installed at each CSNET site for the proper protocols with the name server. 

The user interface with the name server consists of commands to implement these operations: 

register 

unregister 

move 

whois 

update 

The "register" command-is used by a user to enter a new record in the database; the "unregister" com¬ 
mand is used to remove a record; the "move" command is used to change the field in a record indicat¬ 
ing the location of the user’s mailbox. A password scheme prevents unauthorized use of these com¬ 
mands. The "whois" command is used to retrieve a set of records matching keywords; for example 


whois Peter Denning 
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and 


whois past ACM president 

will return the same record. The mailbox identifier field of this record can be extracted and put in a 
local alias table so that future queries can be bypassed. The "update" operation is used by a user to 
alter the descriptive keywords in his record of the database; the system requires him to present his login 
password before installing any changes. 

Future versions of the name server software distributed to CSNET sites will automatically 
encache information locally to reduce traffic with the name server. For example, a user’s alias table 
will hold pairs (nickname, mailbox-identifier) to help avoid unneeded invocations d& the whois com¬ 
mand by that user. A system table will encache pairs (mailbox-identifier, internet address) so that 
unneeded requests for the internet address of a given site can be omitted. Messages will be automati¬ 
cally forwarded to users whose mailboxes have been moved. 

Users at Phonenet sites will have to conduct the above interactions by sending mail to the name 
server. The name server will, by return mail, send records matching a whois query. 


Protocols [5] 

The IP-to-X.25 protocol project is the least visible component of CSNET. Its goal is an interface 
between the datagram-oriented DARPA Internet Protocol (IP) and the- virtual-circuit-oriented X.25 pub¬ 
lic packet network protocol. This interface will enable the high-level ARPA Transport Control Protocol 
(TCP) to work with X.25 nets, which in turn will allow CSNET users full access to ARPANET ser¬ 
vices. Because all user services interact with TCP, any new DARPA network services will become 
available throughout all of CSNET with new software distributions. 
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DARPA’s protocol design relies on the TCP layer in one machine to establish a process-to- 
process channel with a corresponding TCP layer on another machine. The sender’s TCP breaks a mes¬ 
sage into packets, which are handed over to its IP for transmission as independent datagrams over the 
ARPANET. The receiver’s IP hands the received datagrams to its TCP, which reassembles them into 
messages. Purdue’s modification extends IP so that it can selects the Purdue X.25 interface when the 
recipient host’s internet address is on Telenet. 

Because Telenet charges for opening virtual circuits in X.25, the Purdue interface cannot transmit 
an IP datagram simply by opening a circuit, sending a packet containing the datagram, and then closing 
the circuit. Instead, it must leave open a circuit to the target host as long as it or the target is actively 
using that circuit. An algorithm resembling a page replacement algorithm for a viAial memory system 
closes an open circuit when IP requires a new circuit beyond the maximum number Telenet permits a 
given host to open. 

The Purdue interface is connected to an Interactive Systems INcard, which is a board that con¬ 
nects the Telenet modem to the VAX backplane. A future project is to provide the X.29 protocol 
extension of X.25; this will allow the INcard to connect to a login port of UNIX so that authorized 
users can access the machine by ordinary Telenet remote login. Interactive Systems is considering 
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extending the design of its INcard to include X.29 on the board. 


Organization of the Project 

The CSNET management structure provides central management over a project whose com¬ 
ponents are at different locations. Figure 4 outlines the management components. 


PROJECT DIRECTOR 5 

R. Adrion (NSF) s 


MANAGEMENT COMMITTEE 
L. Landweber, Chair 
R. Adrion 
P. Denning 
R. Edmiston 
D. Farber 
A. Hearn 
C. W. Kern 


SUPPORT GROUPS 
Policy (L. Landweber. Chair) 

Technical (D. Farber, Chair) 

Organization (A. Hearn, Chair) 

Coordination & Information Center (R. Edmiston, Director) 


FIGURE 4: CSNET Management Structure. 


The Management Committee consists of the principal investigator of each contract, the director of 


5 


Until October 1982, C. W. Kern of NSF was the project director. 
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the Coordination and Information Center (CIC), and the NSF project manager. This committee meets 
every six to eight weeks to review the status of the project, settle policy questions, and give guidance to 
the technical subprojects. It is responsible for keeping the entire project on schedule and for initiating 
corrective action when needed. Until a separate CSNET organization is established in 1983, the NSF 
project director can overrule the committee on any matter. 

The Policy Support Group consists of the Management Committee plus other senior computer 
scientists.^ It meets as needed (but at least once a year) to review the status of the entire project, give 
general guidance to the Management Committee, and determine overall policies for CSNET. When 
CSNET becomes a separate corporation, this group will be replaced by a board of directors and the 
Management Committee will be replaced by an executive committee. ® 

The Technical Support Group meets from time to time to consider technical problems facing 

n 

CSNET and recommend solutions to the Management Committee. It consists of the principal investi¬ 
gators of each project (or their designees) plus other computer scientists whose technical areas are 
relevant to the project. 

The Organization Support Group has been studying models for the CSNET organization - e.g., 
consortium of universities, embedding in an existing consortium, or separate corporation. It drafted a 
constitution and bylaws that is serving as the charter of CSNET until a formal organization is esta¬ 
blished. After considering the alternatives proposed by this committee, the NSF decided that embed¬ 
ding CSNET into an existing organization would be the best choice; it issued a program solicitation in 


^ As of September 1982, the other members of the Policy Support Group were A. Aho (Bell), B. Arden (Princeton), J. 
Bimbaum (HP). F. Corbato (MTT), K- Curtis (NSF), R. Eckhouse (DEC), N. Habermann (Camegie-Mellon), R. Kahn 
(DARPA), L. Kleinrock (UCLA), M. Marcus (FCC), R. Miller (Georgia Tech), R. Ritchie (Washington), H. Schorr 
(IBM), R. Spinrad (Xerox), and S. Sedelow (Kansas). 

7 

As of September 1982, the members of the Technical Support Group were E. Allman (Berkeley), V. Cerf (MCI), D. 
Crocker (Delaware), P. Enslow (Georgia Tech), J. Feldman (Rochester), L. Hollaar (Utah), J. T. Korb (Purdue), K. 
Lantz (Stanford), M. O’Brien (Rand), J. Postel (USQ, L. Rowe (Berkeley), F. Schneider (Cornell), and M. Solomon 
(Wisconsin). 

g 

As of September 1982, the members of the Organization Support Group were A. Batson (Virginia), W. Franta (Min¬ 
nesota), M. Harrison (Berkeley), G. Heller (EDUCOM), L- Travis (Wisconsin), and K. Uncapher (USQ. 
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October 1982 inviting potential host organizations to submit proposals. 

The Coordination and Information Center is to provide the management services needed to regis¬ 
ter and install new users and sites, distribute CSNET software, provide documentation and regular 
newsletters, and answer users’ questions. After a public announcement in Fall 1981, NSF received and 
reviewed proposals. A contract was awarded to Bolt Beranek and Newman of Cambridge, MA, for this 
function. The CIC became operational in July 1982. 

The CIC has been advising the Management Committee on possible methods of accounting for 

CSNET use and billing sites their fair shares of these charges. The accounting problem is complicated 

by several factors: a) Some messages will travel through several subnets each with different charging 

© 

policies. For example, an east coast Phonenet site will communicate with a west coast Phonenet site by 
two phone calls (site to Delaware relay, Rand relay to site) and a Telenet call (relay to relay), b) It is 
impractical for the relays to provide itemized lists of load generated by each user at a site. It can pro¬ 
vide a total of load generated by a site. The site will have to allocate the cost of that load locally 
among its users; CSNET will provide accounting software for this purpose, c) By agreement with 
DARPA, CSNET will not charge ARPANET users for CSNET use. Assuming that traffic from CSNET 
to the ARPANET is approximately the same as traffic from ARPANET to CSNET. an approach would 
be to charge CSNET users twice the cost of the CSNET leg of their messages to ARPANET users, d) 
Duplex telephone and Telenet circuits can be used by a receiver to send mail back to a caller - at the 
caller’s expense. Special controls may be needed if some frequently called sites are found not to be 
paying usage fees proportional to their actual outbound traffic. 
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Status of the Project 

As of October 1982 both the Rand and Delaware relays were operational. The two relays com¬ 
municated by telephone and ARPANET, and will communicate by Telenet as soon as practicable. 

Some 76 Fhonenet sites were operational or about to become so, as shown by the CSNET map in Fig¬ 
ure 5. 

As of September 1982, a preliminary version of the name server software was being tested at the 
contractors’ sites. All users at all operational CSNET sites were registered in the database. All the 
commands in the user interface were implemented. Later versions making use of the alias facility and 

of encaching internet addresses were under development but were not yet under test 

9 

As of September 1982, the protocol software was under test and was being installed at each of 
the other contractor’s machines. During the test period, all communication among the contractors will 
use Telenet instead of ARPANET. Around January 1983 this software will be available for other 
CSNET sites to install if and when they obtain the necessary Telenet connections. Initial tests revealed 
that Telenet window restrictions limited effective throughput to less than 1200 baud even on lines rated 
at 9600 baud. Negotiations with Telenet were initiated to loosen these restrictions. 

As of July 1982 Bolt Beranek and Newman had been accepted under contract to provide the 
Coordination and Information Center. Complete plans for documentation and software distribution were 
approved by the Management Committee and were being implemented. A hotline phone number was 
operational for any CSNET user or site having questions or comments (617-497-2777). The CIC per¬ 
sonnel had assisted the management committee in devising a dues structure and were assisting in the 
development of accounting and billing procedures. 

As of September 1982 the Policy Support Group had approved a draft of the constitution and 
bylaws of CSNET. Until CSNET is converted to a separate organization, this document will serve as 
the charter. In October 1982, the NSF issued a formal solicitation for an institution to serve as host for 


CSNET, Inc., during the next period. 
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As of September 1982 the Management Committee had received approval from NSF for the dues 
structure (Figure 1) and was proceeding to its implementation. During 1983 member institutions will 
begin paying dues and usage fees. The Coordination and Information Center has provided estimates of 
the annual usage costs that can be expected by each type of site. Examples of costs from these esti¬ 
mates are summarized in Figure 6. 


Site Type 

Initial 

Equipment 

Cost 

Annual 

Connect 

Charges 

Annual 

Usage 

Charges 

Annual 

COST 

PHONENET 
Moderate (1) 
Heavy (2) 

1500 

250 

8750 

24250 

9 

9000 

24500 

TELENET 
Moderate (1) 
Heavy (2) 

10000 

12000 

3250 

9000 

15250 

21000 

ARPANET 

- 

107,000 

- 

- 


(1) Moderate = 10 moderate users plus 10 heavy users. 

(2) Heavy = 20 moderate users plus 30 heavy users. 


FIGURE 6: Example Usage Cost Estimates. 


(These examples assume a moderate user will generate about $250/year charges at Phonenet sites and 
$75/year at Telenet sites; they assume a heavy user will generate about S625/year at Phonenet sites and 
$250/year at Telenet sites.) Phonenet usage charges are a combination of telephone line charges and 
Telenet packet charges for messages that have Telenet legs in their journeys. For a sufficiently active 
site. Telenet is cheaper than Phonenet Moreover, Telenet gives interactive access to CSNET services; 
Phonenet does not. The ARPANET figures are included for comparison: CSNET will be able to pro¬ 
vide similar services at much lower cost to many members of the computer research community. 


As of September 1982 the Management Committee had admitted to membership only U.S. institu- 
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tions conducting or directly supporting computer research. Several industrial applications from firms 
engaged in product development had been deferred until the CSNET organization is more stable and net 
use policies have been set forth. Several applications from foreign research sites (in Canada, Israel, and 
Europe) had been deferred until the U.S. government's policies cm transborder flow in respect to 
CSNET can be ascertained. 


Acknowledgements 

We are grateful to the many colleagues with whom we have interacted during the formative 
stages of CSNET, to the people at NSF and DARPA for their constant advice and encouragement, to 
the National Science Board for its faith in computer community, and to the computer community for its 
continued support for this project. Three persons in government played critical key roles. Bob Kahn 
and Vinton Cerf of DARPA gave constant support and a major commitment of DARPA resources. 

Kent Curtis of NSF spent uncounted hours behind the scenes selling the concept of CSNET to the NSF 
administration, to OMB, and to DARPA; his insistence cm wide community support significantly 
strengthened the project and assured its success. We are also grateful to Fred Schneider and Larry 
Landweber for comments on this manuscript. 


References 

1. Comer, D. E., "The Computer Science Research Network CSNET - A History and Status 
Report," submitted to Communications of ACM, August 1982. 


2. Landweber, L„ and Solomon, M., "Use of Multiple Networks in CSNET," Proc. IEEE COMP- 



CSNET Overview 


- 19 - 


( 12 / 1 / 82 ) 


CON (February 1982). 

3. Crocker, D. H„ Szmkowski, E. S„ and Farber, D. J., "An Inter-Network Memo Distribution Capa¬ 
bility - MMDF," Proc. Sixth Data Communications Symposium, ACM SIGCOMM (1979), 18- 
25. 

4. Landweber, L., Litzkow, L„ Neuhengen, D„ and Solomon, M„ "Architecture of The CSNET 
Name Server," Proc. Symposium on Data Communications, ACM SIGCOMM (March 1983). this 
issue. 

5. Comer, D. E„ and Korb, J. T„ "CSNET Protocol Software: The IP-to-X.25 Interface," Proc. Sym¬ 
posium on Data Communications, ACM SIGCOMM (March 1983), this issue. 

0 






